ndemou Posted May 29, 2013 Report Share Posted May 29, 2013 The PBX gets a SIP UPDATE message from a TELES switch, responds with 200 Ok and then gets a 400 BAD REQUEST. Do you have any idea why I get the BAD REQUEST response? 10:45:11.095852 IP SW.ITCH.ADD.RES.sip > MY.IP.ADD.RES.sip: SIP, length: 731 UPDATE sip:30ANUMBER@MY.IP.ADD.RES:5060;transport=udp SIP/2.0ia: SIP/2.0/UDP SW.ITCH.ADD.RES:5060;branch=z9hG4bK000423DF692817F0347971497FBE From: <sip:30BNUMBER@SW.ITCH.ADD.RES>;tag=8PFK451ICE30000E1D00002l009D4CK0BRRD5Q To: "lala" <sip:30ANUMBER@118408.z89.vpbx.gr;user=phone>;tag=602234505 Call-ID: 90459667@pbx CSeq: 19074 UPDATE Contact: <sip:30BNUMBER@SW.ITCH.ADD.RES:5060> Content-Type: application/sdp Max-Forwards: 70 Supported: 100rel, timer, replaces Content-Length: 213 v=0 o=- 5772220130429104508 1796079628 IN IP4 178.59.102.4 s=session c=IN IP4 IP.AD.DR.81 t=0 0 m=audio 11864 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=ptime:20 a=sendrecv 10:45:11.099819 IP MY.IP.ADD.RES.sip > SW.ITCH.ADD.RES.sip: SIP, length: 646 SIP/2.0 200 Ok Via: SIP/2.0/UDP SW.ITCH.ADD.RES:5060;branch=z9hG4bK000423DF692817F0347971497FBE From: <sip:30BNUMBER@SW.ITCH.ADD.RES>;tag=8PFK451ICE30000E1D00002l009D4CK0BRRD5Q To: "lala" <sip:30ANUMBER@118408.z89.vpbx.gr;user=phone>;tag=602234505 Call-ID: 90459667@pbx CSeq: 19074 UPDATE Contact: <sip:30ANUMBER@MY.IP.ADD.RES:5060;transport=udp> Content-Length: 251 v=0 o=- 608716073 608716074 IN IP4 MY.IP.ADD.RES s=- c=IN IP4 MY.IP.ADD.RES t=0 0 m=audio 57278 RTP/AVP 8 101 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=rtcp-xr:rcvr-rtt=all voip-metrics a=sendrecv 10:45:11.100879 IP SW.ITCH.ADD.RES.sip > MY.IP.ADD.RES.sip: SIP, length: 424 SIP/2.0 400 Bad Request Via: SIP/2.0/UDP MY.IP.ADD.RES:5060;branch=z9hG4bK-ff1858bf689bc0383e22bbb428dfa383;rport=5060;received=MY.IP.ADD.RES From: "lala" <sip:30ANUMBER@118408.z89.vpbx.gr;user=phone>;tag=602234505 To: <sip:30BNUMBER@SW.ITCH.ADD.RES>;tag=8PFK451ICE30000E1D00002l009D4CK0BRRD5Q Call-ID: 90459667@pbx CSeq: 5652 INVITE Reason: SIP;cause=400;text="Bad Request" Content-Length: 0 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted May 29, 2013 Report Share Posted May 29, 2013 Are you sure that the Bad Request comes from the PBX?! AFAIK the PBX never generates a reason cause like this. Maybe you can get a PCAP trace to see if there is any other device that generates the response. Quote Link to comment Share on other sites More sharing options...
ndemou Posted May 29, 2013 Author Report Share Posted May 29, 2013 Are you sure that the Bad Request comes from the PBX?! AFAIK the PBX never generates a reason cause like this. Maybe you can get a PCAP trace to see if there is any other device that generates the response. It's really is not from the PBX. It's comming from the switch in response to the 200 OK that the PBX sends. What I don't know is whether there is something wrong in the contents of the 200 OK that causes the switch to complain. I'm attaching a trace in pcap format. Can you please have a look? Quote Link to comment Share on other sites More sharing options...
ndemou Posted May 29, 2013 Author Report Share Posted May 29, 2013 Can't see my attachment -- retrying trace.pcap.zip Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted May 29, 2013 Report Share Posted May 29, 2013 Okay, first of all, the 200 Ok is for the UPDATE and the Bad Request for the INVITE. So from a SIP call flow perspective, that is okay. I assume that the Bad Request is being sent because the 200 Ok does not have the content-type header set. Codec negotiation while the call is not connected yet is a hassle in SIP. Quote Link to comment Share on other sites More sharing options...
ndemou Posted May 29, 2013 Author Report Share Posted May 29, 2013 [...] I assume that the Bad Request is being sent because the 200 Ok does not have the content-type header set. Codec negotiation while the call is not connected yet is a hassle in SIP. you're probably right --the content-type should probably be there-- is there something I can do to fix this? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted May 29, 2013 Report Share Posted May 29, 2013 Not much. If the switch has a settings that disables the support for UPDATE then you can turn it off. We'll add the Content-Header to the next release; but it is not even a guarantee that the problem is solved. Another workaround could be to set the codec for the trunk to a-law and only to a-law. Then there is no need to send a UPDATE as the codec negotiation becomes trivial. Quote Link to comment Share on other sites More sharing options...
ndemou Posted May 30, 2013 Author Report Share Posted May 30, 2013 Many thanks for the help, I guess I'll find a way workaround it. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.