[Spce-user] 400 Normal Release

[Dave Massey]

Hey thanks for figuring that out!   I have forwarded off the information to the peer but previous attempts at this sort of thing have never gotten anywhere.  
I still have a DTMF problem with this peer. They say they use inband DTMF but it never gets to the subscriber, but the subscriber can send it out.




On 2012-10-19, at 10:23 AM, Jon Bonilla (Manwe) <jbonilla at sipwise.com> wrote:

> El Thu, 18 Oct 2012 18:50:30 +0200
> Jon Bonilla (Manwe) <jbonilla at sipwise.com> escribió:
> 
>> I'm sorry but looks like the error comes from sems somehow. We'll need the
>> ngrep including the communication between the proxy and sems and the sems log
>> with debug enabled.
>> 
>> sems-stats -c "set_loglevel 3"
>> ngrep-sip b port 5060 or port 5062 or port 5080 -q
>> 
> 
> Ok. Thanks for the logs and thaks to sems developers (Frafos GbmH) and Andrew
> Pogrebennyk for taking a look to the logs. It was easier than expected but I
> didn't see it (shame on me!)
> 
> The invite we send to the peer is as follows:
> 
> U 2012/10/18 12:55:34.746152 SPCE_IP:5060 -> PEER_IP:5060
> 
> INVITE sip:19057722572 at PEER_IP:5060;transport=udp SIP/2.0'
> Record-Route:
> <sip:SPCE_IP;r2=on;lr=on;ftag=4BA41CEB-50803486000B6042-82053700;ngcplb=yes>'
> 
> Record-Route:
> <sip:127.0.0.1;r2=on;lr=on;ftag=4BA41CEB-50803486000B6042-82053700;ngcplb=yes>'
> 
> 
> And the 183 we get back from the peer is like this one:
> 
> U 2012/10/18 12:55:36.555972 PEER_IP:5060 -> SPCE_IP:5060
> SIP/2.0 183 Session Progress'
> 
> Record-Route:
> <sip:SPCE_IP;r2=on;lr=on;ftag=4BA41CEB-50803486000B6042-82053700;ngcplb=yes>'
> 
> Record-Route:
> <sip:PEER_IP:5060;r2=on;lr=on;ftag=4BA41CEB-50803486000B6042-82053700;ngcplb=yes>'
> 
> 
> 
> It looks like the peer is substituting it's own IP address
> PEER_IP:5060 where 127.0.0.1:5060 should be sent in the record-router header.
> Due to that, sems can't route the ACK back when the call is answered and the
> peer releases the call with a 400 (This is also something I've never seen
> before) response. 
> 
> We've seen this behaviour in some Audiocodes gateways before and that a wrong
> behavious from your peer server.
> 
> You have two choices: Report the behaviour to your peer and expect them to
> solve their bad behaviour or you can change the internal ip address of you
> sip:provider from 127.0.0.1 to something else (networking.iaddress in
> config.yml) to something else. Create a dummy interface with some private ip
> address and set that parameter to that value. I would do both :)
> 
> 
> 
> 
> 
> 
>