My guess would be that in the field, he has already deployed some servers which expect the To: field to be composed like that :) When I'll have a chance, I'll ask.

Anyway, I have tweaked the sofia_presence.c in a rather ugly way, hard coding the reference from the Contact: header
--- src/mod/endpoints/mod_sofia/sofia_presence.c        2011-08-18 05:55:20.000000000 -0400
+++ src/mod/endpoints/mod_sofia/sofia_presence.c_tweaked        2011-08-18 05:51:04.000000000 -0400
@@ -2160,11 +2160,13 @@
        }

        if (to) {
-               to_str = switch_mprintf("sip:%s@%s", to->a_url->url_user, to->a_url->url_host);
+               //to_str = switch_mprintf("sip:%s@%s", to->a_url->url_user, to->a_url->url_host);
+               to_str = switch_mprintf("sip:%s@%s", contact_user, to->a_url->url_host);
        }

        if (to) {
-               to_user = to->a_url->url_user;
+               //to_user = to->a_url->url_user;
+               to_user = contact_user;
                to_host = to->a_url->url_host;
        }

So far I haven't seen any downside of this hack.

Regards,
Tom

On Wed, Aug 17, 2011 at 6:59 PM, Michael Collins <msc@freeswitch.org> wrote:
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




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