Another SIP dialog / session problem

[Mikael Magnusson]

Werner Dittmann wrote:
> 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.
> 

I think the problem is that Minisip doesn't accept the iLBC codec in the 
answer since the fmtp attribute is missing. In this case Minisip should 
terminate the call with BYE after sending ACK.

Can't you build the Minisip gsm codec? Gsm is supported by Gizmo.

Mikael