Another SIP dialog / session problem

[Werner Dittmann]

Thanks for the fast reply.

As for the CASE-2 ACK topic:
the response (SIP 200 OK) received from Gizmo contains several media
choices. After looking into rfc3261 it seems to me that minisip should
choose one of the media choices contained in the answer and use it to
setup the RTP session. As I can see from minisip's debug output this
is not done.

Minisip's offer in the INVITE contains several media choices, among
them telephone-event/8000, also Gizmo's answer contained a
"telephone-event/8000", both with the same rtpmap number.

Thus I thought minisip should chose 101 and set this as RTP payload
type. Then I discovered that the minisip offer contained the additional
attribute fmtp:101 0-15.

The Gizmo answer does not contain this additional field. I checked the
code to see if this could be the reason why minisip did not choose this,
but I didn't see any problem at the first glance (only for iLBC the fmtp
attribute is checked). So the question remains why minisip des not find
a receiver / sender for this answer.

Also if minisp does not find a matching media it should send an ACK
immediatly followed by a BYE - minisip does send an ACK but not a BYE
immediatly. The BYE seen in the tcpdump was bacuse I pushed the hangup
button after some seconds. This would be a protocol error if minisip
does not find a media match.

Any ideas? Thoughts?

Regards,
Werner



Mikael Magnusson wrote:

<snip> ...... <snap>


>> CASE-2
>>
>> This time my friend answered the phone (can be seen at the OK line, it's
>> his Gizmo client). Minisip prodices an ACK, this time it seems that the
>> correct TAG tag is used. What makes me wonder here is: the media line
>> containes quite a lot of variants to choose from (refer to the first
>> OK Status. Minisip's debug shows this also. However, there is _no_ line
>> saying that a receiver was found and/or enabled (as it is the case in
>> CASE-1 above). Unlike to CASE-1 the whole ALSA stuff was not setup.
>> In addition the ACK packet sent by minisip does not contain
>> a selected media. This is IMHO required in the ACK if we can support
>> one of the media itmes. Otherwise an immediate BYE shall follow the ACK.
>>
> 
> A SDP answer is only sent in an ACK when the initial INVITE didn't
> contain an SDP offer. Instead the offer is sent in the 200 OK response
> by the server, which need to be answered by the client by a SDP answer
> in the ACK.
> 
>> As can be seen in tcpdump.11 my friend's Gizmo resends the OK to get
>> a valid ACK that contains our SDP. In CASE-1 the responder already
>> narrowed
>> down the media selection to one item in the OK already. Thus sending
>> an ACK without further info is ok.
>>
> 
> I don't know why the 200 OK was resent, but it's not because of a
> missing SDP body. Maybe because the ACK was lost or arrived late.
> 
>> Traces: refer to text file, Minisip debug output labeled CASE-2 and file
>>     tcpdump.11
>>
> 
> Same problem with request URIs as in the first case.
> 
>> I packed the trace files (1 text file, 2 tcpdump files) in a tar and
>> compressed with gzip.
>>
>> Regards,
>> Werner
> 
> Mikael
> _______________________________________________
> Minisip-devel mailing list
> Minisip-devel at minisip.org
> http://lists.minisip.org/mailman/listinfo/minisip-devel
>