Another SIP dialog / session problem

[Mikael Magnusson]

Werner Dittmann wrote:
> CASE-1
> 
> While testing the latest patch (2646) I tried to get my friend to test
> the patch. He wasn't at home and didn't answer the phone - thus I got
> a voice announcement from sipphone telling me that he has no voicemail.
> 
> In the middle of th announcement I pressed the hangup buttom. Then Minsip
> started to send BYe again and again. After a while I received a BYE from
> sipphone - but minisip didn't stop sending BYE. I can't see why this
> happens and the receiver does not nonor our BYE (IMHO the receiver shall
> send an OK to the BYE, shouldn't it?).
> 
> Traces: refer to text file, Minisip debug output labeled CASE-1 and file
> 	tcpdump.10
> 

I don't know if it's causing the problems, but Minisip doesn't use the 
complete remote contact URI in the request URI of the ACK and BYE. The 
URIs should contain the "nat=yes" parameter, but it's missing since 
Minisip ignores all URI parameters it doesn't understand. This need to 
be fixed.

> 
> 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