Another SIP dialog / session problem

[Werner Dittmann]

Well, I'll try to enable the GSM stuff in the next build. I need to find
the gsm codec lib and install it first.

Regarding the lookup - as far as I understand the code (in several modules):

- if a match is found: register the receiver with RtpReceiver to handle
  this payload type. This is done for every match. This way the
  receiver is able to handle every incoming media type that was in
  the answer.
- register the sender with the media that was found as the last in
  the media list offered.

Thus the only thing missing is to return a false if no match is found
at all and act accordingly with repect to ACK/BYE.

The options Zach proposed would apply to the sender side and may be
done as an extension.

Regards,
Werner

Zach Welch wrote:
> Mikael Magnusson wrote:
>> Werner Dittmann wrote:
> [snip]
>>> 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.
> [snip]
>> 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.
> [snip]
> 
> RFC3952 (where the RTP payload format for iLBC is defined) shows an
> example in section 5 that does not contain the mode attribute. Section
> 4.2 lists the valid modes are 0, 20, and 30; however, the entire
> parameter itself is optional.
> 
> As such, I would think minisip should simply accept the modeless answer
> and use what it offered. This seems like a valid way of interpreting the
> following paragraph in section 5:
> 
>   The offer contains the preferred mode of the offerer. The answerer
>   may agree to that mode by including the same mode in the answer, or
>   may include a different mode. The resulting mode used by both
>   parties SHALL be the lower of the bandwidth modes in the offer and
>   answer.
> 
> It happens that "a different mode" could be "no mode at all", since the
> parameter does not appear to strictly be required.  (Or at least, that
> appears to be how Gizmo has interpreted the spec.)
> 
> Certainly, I would be interested to see what happens if that match was
> allowed in this test case (or others).
> 
> Cheers,
> 
> Zach
> _______________________________________________
> Minisip-devel mailing list
> Minisip-devel at minisip.org
> http://lists.minisip.org/mailman/listinfo/minisip-devel
>