I thought that would be the issue as well when I dove into this but after a
couple of hours of log digging and tcpdumps I'm confident the SPA 3102 is
sending a Contact field but it is not making it back out of the sipx proxy.
Maybe its malformed in some subtle (to me) way?
Here's an extract from the packet (as seen by a span tap) as it comes out of
the SPA headed to sipxProxy.
Note: I have a patch that's putting quotes around the malformed From: and
Remote-Party-ID fields and the merged.xml I sent yesterday shows that's working
as expected (and shouldn't affect the Contact field in any case).
-Eric
Internet Protocol, Src: 192.172.252.21 (192.172.252.21), Dst: 192.172.252.163
(192.172.252.163)
Source: 192.172.252.21 (192.172.252.21)
Destination: 192.172.252.163 (192.172.252.163)
User Datagram Protocol, Src Port: sip-tls (5061), Dst Port: sip (5060)
Source port: sip-tls (5061)
Destination port: sip (5060)
Session Initiation Protocol
Request-Line: INVITE sip:[email protected] SIP/2.0
Method: INVITE
Request-URI: sip:[email protected]
Request-URI User Part: 0
Request-URI Host Part: d3.foo21.com
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 192.172.252.21:5061;branch=z9hG4bK-5c3fd3ea
Transport: UDP
Sent-by Address: 192.172.252.21
Sent-by port: 5061
Branch: z9hG4bK-5c3fd3ea
From: SMITH,A <sip:[email protected]>;tag=6e8b9fe8ed9f4d3ao1
SIP Display info: SMITH,A
SIP from address: sip:[email protected]
SIP from address User Part: 17635191497
SIP from address Host Part: d3.foo21.com
SIP tag: 6e8b9fe8ed9f4d3ao1
To: <sip:[email protected]>
SIP to address: sip:[email protected]
SIP to address Host Part: d3.foo21.com
Remote-Party-ID: SMITH,A
<sip:[email protected]>;screen=yes;party=calling
Call-ID: [email protected]
CSeq: 101 INVITE
Sequence Number: 101
Method: INVITE
Max-Forwards: 70
Contact: "PSTN FXO1" <sip:[email protected]:5061>
Contact Binding: "PSTN FXO1" <sip:[email protected]:5061>
URI: "PSTN FXO1" <sip:[email protected]:5061>
SIP Display info: "PSTN FXO1"
SIP contact address: sip:[email protected]:5061
Expires: 240
User-Agent: Linksys/SPA3102-5.1.10(GW)
Content-Length: 452
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: x-sipura, replaces
Content-Type: application/sdp
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 138901891 138901891 IN IP4
192.172.252.21
...
-Eric
On Jan 3, 2010, at 11:30 PM, Scott Lawrence wrote:
> On Sun, 2010-01-03 at 17:19 -0600, Eric Varsanyi wrote:
>> MikeJ of the FreeSwitch project sent me a patch (thank you!) that just
>> ignores the lack of a Contact header when processing the NOTIFY
>> message. This does fix the immediate problem (FreeSwitch doesn't SEGV
>> and I can press 'Reject' as soon as I like and the caller goes to
>> voicemail) but it still seems "wrong" (per the RFC) that the Contact
>> header is missing on the NOTIFY/Ringing... message from sipXproxy.
>>
>> I'm happy to help (try patches/more testing/whatever), even a shove in
>> the right direction as to where to dig deeper.
>
> You're correct that it is a bug not to send a Contact in that NOTIFY,
> but you've got the wrong culprit. The sipXproxy is just forwarding it -
> that message comes from the Linksys and didn't have a Contact there
> either, so you'll have to take it up with them.
>
> If you'd like, and you can't file an issue with Linksys in some public
> place, you can file an issue in the External project at
> track.sipfoundry.org to record the facts. You've done a good job of
> documenting the problem (the messages in a sipviewer trace have frame
> numbers - it's easier to identify them that way than copying them, but
> that's a nit... good job).
>
>
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
