I'm working on script for automated calls via SIP and ran into a problem with the Caller ID.
The script runs quite simple:
Calls the customer by his phone (for example, +1234567890) via INVITE method
When the customer answers the call, uses REFER method to transfer the call to his personal manager.
Manager receives the incoming call with the dialog established with the customer.
At the step 2-3 manager always receives the call from the contact called s#1.2.3.4 (where 1.2.3.4 is the IP address of our SIP server). How can I set the customers phone instead of s#1.2.3.4 ?
The refer request I use looks like this:
REFER sip:+1234567890#1.2.3.4:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.1:5100;rport;branch=z9hG4bK160892
From: <sip:100#192.168.1.1>;tag=29899
To: <sip:+1234567890#1.2.3.4:5060>
Call-ID: 28990ec994a682147cf87eda75f97664#192.168.1.1
CSeq: 22 REFER
Contact: <sip:100#192.168.1.1:5100>
Max-Forwards: 70
Refer-to: sip:111#1.2.3.4
Referred-By: <sip:+1234567890#1.2.3.4:5060>
Content-Length: 0
Here 100 is SIP ID of the call robot, 192.168.1.1 is the IP of robot, 111 is SIP ID of manager.
I tried using Refer-To like these:
Refer-to: <sip:111#1.2.3.4?Call-ID=28990ec994a682147cf87eda75f97664#192.168.1.1&From=%3Csip%3A%2B1234567890%401.2.3.4%3A5060%3E&Contact=%3Csip%3A%2B1234567890%401.2.3.4%3A5060%3E>
Refer-to: <sip:111#1.2.3.4?Call-ID="69ca6b4e1874aa07569ee234cf746a3c#192.168.1.1"&From="<sip:+1234567890#1.2.3.4:5060>"&Contact="<sip:+1234567890#1.2.3.4:5060>">
Refer-to: <sip:111#1.2.3.4;method=INVITE?Call-ID="d71d3cc87f88eb1522859296889d39fb#192.168.1.1"&From="sip:+1234567890#1.2.3.4:5060"&Contact="<sip:+1234567890#1.2.3.4:5060>">
But nothing worked as I expected, caller ID of the incoming manager's call still was s#1.2.3.4. The correct caller ID is required for us to get call recordings.
SIP software used: Kerio Operator (based on Asterisk).
What Refer-To or other headers can I use to send the correct caller ID?
First some remarks regarding the REFER request:
The Referred-By header should contain the referrer's SIP URI, not the referee's SIP URI.
The REFER request should be sent within the existing dialog. It appears you send the REFER request outside of any dialog (no to-tag provided).
From your description I derive that you use a B2B SIP server. That means when the customer's phone (+1234567890#1.2.3.4) receives the REFER request, the resulting INVITE request will be sent to the SIP server (s#1.2.3.4). The SIP server will then create a new INVITE request and send this to the manager's phone (111#1.2.3.4).
The INVITE request from SIP server to manager's phone will contain the following values:
to header --> 111#1.2.3.4
from header --> +1234567890#1.2.3.4
contact header --> s#1.2.3.4
The manager's phone then has to use the from header's value as caller ID, not the contact header's value.
You might want to check
if the INVITE request contains the right header values
if the manager's phone uses the right header to determine the caller ID.
I hope this helps.
Related
I have a chat client that can be incorporated into multiple hosts, the chat client is independent.
User A logs in at two places - say chrome and firefox
So User A sends Message User B, User B receives the message, chat message is displayed at both sides.
Now User A has logged in at the window in the separate browser also, I want to push the message and display the message here also
Just like if you open a Gmail chat window at multiple browsers, then the sent message is pushed at both the ends.
XMPP protocol define JID as following:
JIDs consist of three main parts:
The node identifier (optional) The domain identifier (required) The
resource identifier (optional) JIDs are encoded UTF-8. A grammar will
be presented first, followed by specific clarifying and further
restricting remarks.
or in s simpler language you JID is built from:
Username#YourDomain.com/Resource
one user can have many resources,
for example:
prashantsahni#domain.com/phone
prashantsahni#domain.com/firefox
prashantsahni#domain.com/chrome
just set up the right resource for the user each time and let the XMPP Server to take care of the rest.
and you can look at this post to see how to do it with strophe
tou can read more about it in here:
https://xmpp.org/extensions/xep-0029.html
I am using message carbon.
There is a plugin provided by strophe. - strophe carbon
I have implemented using message carbons. The XEP is given here. For this to work you will need to check if the server supports this XEP. Most servers, Ejabberd, MongooseIM, Openfire, etc., supports the extension. The server will forward the message carbon to each resource. Once you have enabled message carbons in your server, all you need is to take care of the stanza which is being forwarded to you from each resource for a JID.
Lets say the JID for user A and user B is userA#domain.com and userB#domain.com, and you login to both chrome and firefox using the full JIDs below:
userA#domain.com/chrome
userA#domain.com/firefox
Now when you start sending message to user B from chrome, the message will be sent to your XMPP server which then also forwards the same message to your firefox browser. Lets say if the original message stanza sent from chrome is as follows:
<message xmlns='jabber:client'
from='userA#domain.com/chrome'
to='userB#domain.com'
type='chat'>
<body>What man art thou that, thus bescreen'd in night, so stumblest on my counsel?</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message>
You should receive the forwarded stanza in your firefox as follows:
<message xmlns='jabber:client'
from='userA#domain.com'
to='userA#domain.com/firefox'
type='chat'>
<received xmlns='urn:xmpp:carbons:2'>
<forwarded xmlns='urn:xmpp:forward:0'>
<message xmlns='jabber:client'
from='userA#domain.com/chrome'
to='userB#domain.com'
type='chat'>
<body>What man art thou that, thus bescreen'd in night, so stumblest on my counsel?</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message>
</forwarded>
</received>
</message>
You need to extract original message from the forwarded stanza. Also note that you can use each browser tab as a separate resource. You might also want to configure the maximum number of resources the server can handle at a time for a user.
I have a question regarding "Supported:histinfo" in incoming INVITE.
If the following example is a valid INVITE message? That is, it has "Supported:histinfo", but it actually uses Diversion header.
What does "Supported:histinfo" means? Only means the sender supports History-Info?
INVITE sip:7654321#xx.xx.xx.xx:5060 SIP/2.0
Supported: histinfo
Diversion: <sip:+12345678#1.2.3.4;user=phone>;reason=unconditional;counter=1
From RFC4244,
A new Supported header, "histinfo", is included in the Request to
indicate whether the History-Info header is returned in Responses
(BACKWARDS-req).
So, seems that the above example is a valid one.
Thanks,
Ted
I have a trivial doubt with respect to SIP.
I tried googling and referring many books, but still I am not able to find a solid reason for adding from-tag in SIP request.
Example SIP request (Snapshot from rfc-3261)
INVITE sip:bob#biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob#biloxi.com>
From: Alice <sip:alice#atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710#pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice#pc33.atlanta.com>
Content-Type: application//sdp
Content-Length: 142
As per rfc-3261:
Dialog can be identified using from-tag, to-tag and call-id.
I know the precise reason for adding to-tag and call-id. What I don't know is,
Why do we need from-tag ?
What would be the impact if from-tag was absent (assuming that
rfc-3261 doesn't mandates it)?
#Ani, here is one realistic example when you can say why "From-tag" is really required. In case of re-INVITE, when it was done from the called party/terminating number from the initial INVITE, the To and From header gets exchanged, and so the From tag and To-Tag.
Example link: Example re-invite flow
Assume A sends initial INVITE to B, From header has A's tag (local tag), To Header has B's tag (remote tag). later after call accepted, B sends a re-INVITE to A, in this re-INVITE, From Header has B's sip uri with B's tag, and TO header has A's sip uri with A's tag. Now for this case B's tag become local tag and A's tag become remote tag.
Now if you think if From-tag wasn't there in initial INVITE itself, there will be no To-Tag in re-INVITE, and difficult to identify the recipient.
[EDIT]
About the meaning of the attribute "tag" inside the header field From, here is your answer : http://andrewjprokop.wordpress.com/2013/09/23/lets-play-sip-tag/
Removing the tag would simply invite servers to consider messages as duplicated.
To resume what Andrew Prokop wrote :
The most obvious problem with using Call-ID to uniquely identify a
message arises with call forking. In call forking, a single SIP
Invite message is turned into multiple Invite messages to different
destinations. For example, you might call me, Andrew Prokop, but call
forking might cause Invite messages to be sent to all my registered
endpoints — my smart phone, my desk phone, and my PC phone. That
single Call-ID was fine when it was one Invite, but it’s not so fine
when it becomes three. This is where tags come in.
Tags are really quite simple, but require a bit of explanation. The
goal of a tag is to work with the Call-ID to make an entire dialog
unique no matter how many times a session might be forked. Actually,
I should have said tags since there are two. There is the local tag
(From tag) which is assigned by the sender of a message or the UAC.
There is also the remote tag (To tag) which is assigned by the final
recipient of the message or the UAS (User Agent Server). The UAC puts
its tag in the From header and the UAS puts its tag in the To header.
So, when a message leaves a UAC it has one tag in the From header and
there is no tag in the To header. When a UAS receives that message
and responds back with a SIP response (e.g. 180 Ringing), it then adds
a tag to the To header. If multiple clients received the original
message then they would all add their own specific tag values. In
other words, all those SIP messages will have the same From tag, but
depending on who is responding, there will be different To tags.
From Tag is UAC's identifier for the Dialog other than the Call-Id. Combined they provide unique nature to the dialog.
Other use cases
Hair-pinning / Tromboning - although different services, they both rely on the FROM tag to distinguish the call direction based on Dialog tags.
Sending Multiple INVITE for interworking with PSTN where the IAM and subsequent Digits in SAM are carried in the INVITE and the same FROM Header. Helps downstream Gateways to match it specific dialogs. RFC 3578 has more details. So in this case the FROM Tag for the same call helps the GW determine how to handle the INVITE containing further digits.
"From" field is for request initiator info.
Try this PDF http://www.sipknowledge.com/rfc3261_explained_light.zip
Section 8.1.1.3 "From"
Also, section 8.3.1 says that From field is a mandatory, as one of fundamental blocks in any SIP request.
First of all, I was also looking answer for the same.
Yes, CALL-ID serves purpose.
But From & To tag is used to handle SIP advances.
As many New features getting included in SIP call.
But 3 needful :(there could be many)
If the From address can appear in requests generated by other user agent clients for the same call, the caller MUST insert the tag parameter in the From field.
https://www.ietf.org/rfc/rfc2543.txt
Latest: JOIN header used FROM & TO tag for validation. Suppose 2 people are talking and another one wants to JOIN the call.
RFC3911- The Session Initiation Protocol (SIP) "Join" Header
https://www.rfc-editor.org/rfc/rfc3911.txt
used to validate the subsequent request:-
11.5 Receiving Subsequent Requests
When a request is received subsequently, the following checks are
made:
1. If the Call-ID is new, the request is for a new call,
regardless of the values of the To and From header fields.
2. If the Call-ID exists, the request is for an existing call.
If the To, From, Call-ID, and CSeq values exactly match
(including tags) those of any requests received previously,
the request is a retransmission.
3. If there was no match to the previous step, the To and From
fields are compared against existing call leg local and
remote addresses. If there is a match, and the CSeq in the
request is higher than the last CSeq received on that leg,
the request is a new transaction for an existing call leg.
Just like the recipient. The call originator could have multiple devices. An IP-Phone, Call processing agent or IP Communicator on Laptop. The different from tags from the call could help identify the device where the call is coming from. Also as mentioned above, it could help to call back the orginal device incase the recipient calls the originator back.
I'm writing a SIP client, and I'm having some weird issues when using SUBSCRIBE to an existing client (different, freeware software)
I'm using my own server, but it's not the problem because if I'm doing a SUBSCRIBE from a different client (pjsip), it all works fine.
I'm sending out this SUBSCRIBE message:
SUBSCRIBE sip:3009#10.0.0.4 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.7:5060;rport;branch=z9hG4bKPj3893ccd****************
Max-Forwards: 70
From: <sip:10.0.0.7>;tag=023a965a14a143eb8*******
To: sip:3009#10.0.0.5;tag=8cfb7*********
Contact: <sip:10.0.0.7:5060;ob>
Call-ID: bf5d48fe8ca0***************
CSeq: 14388 SUBSCRIBE
Route: <sip:10.0.0.5;lr;ftag=023a965a14a143eb8*********>
Event: presence
Expires: 600
Supported: replaces, 100rel, timer, norefersub
Accept: application/pidf+xml, application/xpidf+xml
Allow-Events: presence, message-summary, refer
Content-Length: 0
After that message, an OK is received, but then I'm receiving a NOTIFY message for every presence change that the other client did since HE registered to the server.
The problem doesn't happen with different clients..
If it matters, I'm developing on Visual Studio 2008 on Windows 7 64bit
Any ideas?
Thanks!
From the comments the issue seems to be that you are not sending a valid response to the client and therefore it is sending multiple retransmits of each NOTIFY request.
To generate a valid response the key aspect is that you have to set the Via branch parameter and CSeq to the same values as the request, see RFC 3261, section 17.1.3.
I am trying to SUBSCRIBE to a watcher list and the server frequently responds with 486 BUSY HERE. However, the RFCs describe 486 as a possible response for an INVITE, which make more sense for this response. At other times, the server does respond correctly - with a 200 OK, followed by a NOTIFY request.
I am working with an ALU IMS core.
Has anyone seen this issue?
My SUBSCRIBE Request:
SUBSCRIBE sip:yyyyyyyyyyy#example.com;transport=TCP SIP/2.0
Call-ID: 81fcd7229c882f230c726e21f16aadc9#10.0.2.15
CSeq: 4 SUBSCRIBE
From: "XXXX" <sip:yyyyyyyyyyy#example.com>;tag=92521573
To: <sip:yyyyyyyyyyy#example.com>
Via: SIP/2.0/TCP 10.0.2.15:5060;branch=z9hG4bK68630e2ec7c21d2e991854010b7f64543332
Max-Forwards: 70
Contact: <sip:yyyyyyyyyyy#10.0.2.15:5060;transport=TCP>;+g.oma.sip-im;expires=3600
User-Agent: My Android Client/OMA1.0
Require: pref
Supported: replaces,100rel,eventlist,timer
Event: presence.winfo
Accept: application/watcherinfo+xml
Route: <sip:yyyyyyyyyyy#z.z.z.z:5060;transport=TCP;lr>
Expires: 3600
Content-Length: 0
The thing to remember with SIP response codes is there are no hard and fast rules about which specific response code should be used in all situations. Invariably a real World error condition on a SIP server or UAS does not fall neatly into the definition of one of the SIP failure response codes so the closest one is used and the status message may be customised and/or a Warning header added.
The 486 response is a little bit unusual for a SUBSCRIBE request but it could easily make sense. For example if the SIP notification server maintaining the subscriptions has a limit on how many active subscriptions it will maintain or if it's overloaded and doesn't want to process subscription requests for a while.
I'd have a closer look at the 486 response and see if there is a Warning or any other informational type header. Also check whether the response is coming from the intermediate proxy you are using or the end server.
486 is not a response code define in RFC3265. You need to trace your server (if possible) to understand why it decided to send such an unexpected error code.
Sorry for not being much help. I have been working with SIP for several years and never heard of a 486 response for a SUBSCRIBE request. When you find out the reason I'd like to know about it too.