SDP of 200 OK "m=text m=text 0 RTP/AVP" does not follow value on receiving INVITE

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Send Invite request to Boghe 
2.SDP of 200 OK "m=text m=text 0 RTP/AVP" does not follow value
3.Java sip.servlet cannot recognize the end of 200 OK message, so application 
does not return ACK response to Boghe.

What is the expected output? What do you see instead?
current format: m=text 0 RTP/AVP
expected format: m=text 0 RTP/AVP n (value)

What version of the product are you using? On what operating system?
Boghe_2.0.100.701
Windows/XP

Please provide any additional information below.
Sip log file is attached.

Original issue reported on code.google.com by amano.ha...@gmail.com on 7 Jun 2012 at 7:46

Attachments:

• sip_boghe.log

[GoogleCodeExporter]

Hello my explanation may not be enough.

I am expecting Boghe would return 200 OK with same m=text line value as 
received Invite.

Please look into the attached file.
The Invite request from application has m=text 38582 RTP/AVP 105 106.
And expecting Boghe to return the same payload value in 200 OK like below.
m=text 0 RTP/AVP 105 106

Regards,
Amano

Original comment by amano.ha...@gmail.com on 7 Jun 2012 at 9:15

[GoogleCodeExporter]

Could you please attach wireshark trace?

Original comment by boss...@yahoo.fr on 7 Jun 2012 at 4:41

• Changed state: Accepted

[GoogleCodeExporter]

Attached is the wireshark trace.

Thank you and regards,
Amano

Original comment by amano.ha...@gmail.com on 8 Jun 2012 at 1:47

Attachments:

• boghe.cap

[GoogleCodeExporter]

Boghe returns "m=text 0 RTP/AVP" which is correct. AFAIK the payload types are 
not mandatory unless you can point to a RFC.

Original comment by davidplo...@gmail.com on 8 Jun 2012 at 1:53

[GoogleCodeExporter]

Hi,

SDP is used to negotiate which payload type is used between caller and callee.
For this case, caller indicates to support 106(T140) and 105(T140RED) in 
Invite. If callee does not set any value in 200 OK response, the negotiation 
cannot be done at caller side. The callee should return 488 "Not Acceptable 
Here" instead of 200 OK if he cannot support it.
I am not sure RFC describes the value in 200 OK is mandate or not,but I think 
it does not make sense to send 200 OK without any value for the purpose of 
negotiation.

Best regards,
Amano
P.S. I tried X-Lite and saw he set the same value as that of Invite and the 
call has been established successfully.

Original comment by amano.ha...@gmail.com on 8 Jun 2012 at 5:31

[GoogleCodeExporter]

FYI, Attached is the X-Lite wireshark trace.

Original comment by amano.ha...@gmail.com on 8 Jun 2012 at 6:30

Attachments:

• Xlite.cap

[GoogleCodeExporter]

Your diagnostic is completely wrong. Xlite is not a reference. You should read 
the RFC by yourself.
488 response is only returned if the session cannot be handled. In this case 
audio and video media are ok and this is why we don't return 488 (same as 
xlite).
"text" media cannot be handled and this is why the port is equal to zero in 
xlite and Boghe. The media line MUST only contains supported codec, in this 
case none is supported for "text".
You even didn't understood that xlite is rejecting the "text" media (NO 
NEGOTIATION) by setting the port number to zero. So, don't tell us: "I think it 
does not make sense to send 200 OK without any value for the purpose of 
negotiation."

Original comment by boss...@yahoo.fr on 8 Jun 2012 at 7:01

• Changed state: Invalid

[GoogleCodeExporter]

ok. i will use xlite.

Original comment by amano.ha...@gmail.com on 8 Jun 2012 at 7:53