This is interesting. I'm looking at the SIP book by Alan Johnston (one of the guys who authored the SIP spec) and I can't see any indication that the To: field can contain an invalid URI like that. Question: why, exactly, does the client feel that it needs to violate such a basic principle? -MC On Tue, Aug 16, 2011 at 7:58 AM, Lorem Ipsum <lrmipsum0@gmail.com> wrote:
Hello,
I'm testing a SIP stack for an embedded device. The device, among other things, is capable of informing a user about pending messages on the voicemail. It does that by subscribing to the message-summary. Below some wireshark traces (172.16.30.68 is my device, 172.16.31.10 is FreeSWITCH):
REGISTER sip:172.16.31.10 SIP/2.0 Via: SIP/2.0/UDP 172.16.30.68:5080 ;rport;branch=z9hG4bKPj051b000000035ea40edf Route: <sip:172.16.31.10:5060;lr> Max-Forwards: 70 From: <sip:399510002@172.16.31.10>;tag=051b000000025ea40edf To: <sip:399510002@172.16.31.10> Call-ID: 051b000000015ea40edf CSeq: 1 REGISTER Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY User-Agent: My_Sip_Device Contact: <sip:399510002@172.16.30.68:5080>;transport=udp Content-Length: 0
SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 172.16.30.68:5080 ;rport=5080;branch=z9hG4bKPj051b000000035ea40edf From: <sip:399510002@172.16.31.10>;tag=051b000000025ea40edf To: <sip:399510002@172.16.31.10>;tag=mQrcXUcvrtUmS Call-ID: 051b000000015ea40edf CSeq: 1 REGISTER User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-38e3f5f 2011-08-09 03-09-19 -0400 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, precondition, path, replaces WWW-Authenticate: Digest realm="172.16.31.10", nonce="3139f996-c814-11e0-93d2-05aa0ee343d6", algorithm=MD5, qop="auth" Content-Length: 0
REGISTER sip:172.16.31.10 SIP/2.0 Via: SIP/2.0/UDP 172.16.30.68:5080 ;rport;branch=z9hG4bKPj051b000000065ea40edf Route: <sip:172.16.31.10:5060;lr> Max-Forwards: 70 From: <sip:399510002@172.16.31.10>;tag=051b000000045ea40edf To: <sip:399510002@172.16.31.10> Call-ID: 051b000000015ea40edf CSeq: 2 REGISTER Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY User-Agent: My_Sip_Device Contact: <sip:399510002@172.16.30.68:5080>;transport=udp Authorization: Digest username="399510002", realm="172.16.31.10", nonce="3139f996-c814-11e0-93d2-05aa0ee343d6", uri="sip:172.16.31.10", response="1e95409a562c074cbe6df148a85107ef", algorithm=MD5, cnonce="051b000000055ea40edf", qop=auth, nc=00000001 Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 172.16.30.68:5080 ;rport=5080;branch=z9hG4bKPj051b000000065ea40edf From: <sip:399510002@172.16.31.10>;tag=051b000000045ea40edf To: <sip:399510002@172.16.31.10>;tag=N0H5ypXZN3H7m Call-ID: 051b000000015ea40edf CSeq: 2 REGISTER Contact: <sip:399510002@172.16.30.68:5080>;transport=udp;expires=180 Date: Tue, 16 Aug 2011 14:29:47 GMT User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-38e3f5f 2011-08-09 03-09-19 -0400 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, precondition, path, replaces Content-Length: 0
SUBSCRIBE sip:172.16.31.10 SIP/2.0 Via: SIP/2.0/UDP 172.16.30.68:5080 ;rport;branch=z9hG4bKPj051b0000000a5ea40edf Max-Forwards: 69 From: "399510002" <sip:399510002@172.16.31.10>;tag=051b000000085ea40edf To: <sip:172.16.31.10> Contact: <sip:399510002@172.16.30.68:5080> Call-ID: 051b000000095ea40edf CSeq: 1 SUBSCRIBE Event: message-summary Accept: application/simple-message-summary Allow-Events: message-summary User-Agent: My_Sip_Device X-Serialnumber: LMZ091218000026 Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY Route: <sip:172.16.31.10:5060;lr> Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 172.16.30.68:5080 ;rport=5080;branch=z9hG4bKPj051b0000000a5ea40edf From: "399510002" <sip:399510002@172.16.31.10>;tag=051b000000085ea40edf To: <sip:172.16.31.10>;tag=p9ay0He3jc8Sg Call-ID: 051b000000095ea40edf CSeq: 1 SUBSCRIBE Contact: <sip:@172.16.31.10:5060> Expires: 60 User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-38e3f5f 2011-08-09 03-09-19 -0400 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, precondition, path, replaces Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Subscription-State: active;expires=60 Content-Length: 0
After sending the 200 OK, FreeSWITCH does not send the NOTIFY. If you look at the Contact header of the answer to the SUBSCRIBE you will notice that the part before the "@" is missing. I guess this is because SUBSCRIBE request does not contain the whole URI, just the host part. That is because our customer wants it done this way; the request line should look like this: SUBSCRIBE sip:voicemail_server SIP/2.0
and the To: header should look like this: To: <sip:voicemail_server>
My question is: how can I make FreeSWITCH (the NOTIFY part anyway, other things are working OK) work with such a device? Thanks.
Regards, Tom
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org