Andy, I'm not sure if this is related to the branch differences -- but that is sort of a known problem. When processing the 200 OK, we are getting confused because of the URL change. I haven't dug into to see if this is a problem in the LineManager or in sipXtapi events.
In the LineManager, it should use the LineId URL parameter to match up the lines, so I don't expect a problem there. I suspect the sipXtapi event stuff is making decisions based on the line identity which isn't matching because the IP has changed. As a short term work around, I believe you can specify a contactId when you add the line -- If you use a STUN-based contactId, that should include the STUN address in the initial contact -- although, I have not tested that recently. - Bob On Monday, August 14, 2006, 3:50:23 PM, Andy wrote: > I just moved from using media-update to the main branch, and I'm not > getting a LINESTATE_REGISTERED event. I've verified sipxtapi is getting > the SIP packets but not firing the event by enabling a debug log. > Here's a snippet of the SIP messages (the periods on the end of lines is > from ngrep). I've verified both sides are sending/receiving everything > OK with ngrep, Ethereal, and the debug log. > It looks like the REGISTER packet from sipxtapi is putting the private > IP in the contact header, and on the return leg my OpenSER server > correctly inserts the external IP. I'm using STUN, and bind only to one > address. > -Andy > U 67.106.157.244:2647 -> 82.165.187.142:5060 > REGISTER sip:icall.com SIP/2.0. > From: sip:[EMAIL PROTECTED];tag=18be4823. > To: sip:[EMAIL PROTECTED] > Call-Id: 6d017ad66815f613552ce85511c16651. > Cseq: 102 REGISTER. > Contact: > <sip:[EMAIL PROTECTED]:2647;LINEID=2af61b768be2d75af653838201d1a904>. > Expires: 1000. > Date: Mon, 14 Aug 2006 19:43:31 GMT. > Max-Forwards: 20. > User-Agent: iCall. > Accept-Language: en. > Supported: replaces. > Authorization: Digest username="andy", realm="icall.com", > nonce="44e0d38dc54dfb232f987d1a845122f3ac37a7ba", uri="sip:icall.com", > response="7b8afcbd9df92bee96124200b04e7656". > Via: SIP/2.0/UDP > 192.168.15.100:2647;branch=z9hG4bK-ee8db07e9fb99b28b1fb803e59b8525f;rport. > Content-Length: 0. > . > U 82.165.187.142:5060 -> 67.106.157.244:2647 > SIP/2.0 200 OK. > From: sip:[EMAIL PROTECTED];tag=18be4823. > To: sip:[EMAIL PROTECTED];tag=5b46a68c112a2bb140d4044f388872dd.83b0. > Call-Id: 6d017ad66815f613552ce85511c16651. > Cseq: 102 REGISTER. > Via: SIP/2.0/UDP > 192.168.15.100:2647;branch=z9hG4bK-ee8db07e9fb99b28b1fb803e59b8525f;rport=2647;received=67.106.157.244. > Contact: > <sip:[EMAIL > PROTECTED]:2647;LINEID=2af61b768be2d75af653838201d1a904>;expires=1000;received="sip:67.106.157.244:2647". > Server: OpenSer (1.1.0-notls (i386/linux)). > Content-Length: 0. > Warning: 392 82.165.187.142:5060 "Noisy feedback tells: pid=16095 > req_src_ip=67.106.157.244 req_src_port=2647 in_uri=sip:icall.com > out_uri=sip:icall.com via_cnt==1". > _______________________________________________ > sipxtapi-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
