Even in scenario I, if A sends DTMF as TE (even though he didn't declare
it in offer), B is expected to receive it since he declared it in the
answer. However, B MUST not send DTMF as TE since A didn't declare it in
offer. Do it sends it in-band (i.e. in G711Mu). This results in
asymetric DTMF operation (send in one more and receive in one mode).
Most client implementations (due to underlying DSP arch) will have
difficult with this since they mostly have one setting for DTMF mode.
Currently, RFC3264 says:
For streams marked as sendrecv in the answer:
1. the "m=" line MUST contain at least one codec the answerer is
willing
to both send and receive, from amongst those listed in the offer.
2. The stream MAY indicate additional media formats, not listed in the
corresponding stream in the offer, that the answerer is willing to
send or receive (of course, it will not be able to send them at
this
time, since it was not listed in the offer).
To help achieve symmetric modes, I still feel restricting the answer to
a sub-set will help. i.e. with a SHOULD clause in addition to the
current MUST and MAY clauses as below.
3. The stream SHOULD contain a sub-set of media formats listed in the
offer.
Regards
Satya T
-----Original Message-----
From: Rockson Li (zhengyli) [mailto:[email protected]]
Sent: Wednesday, August 19, 2009 12:42 PM
To: T Satyanarayana-A12694; Paul Kyzivat (pkyzivat)
Cc: [email protected]
Subject: RE: [Sip-implementors] Can EP send media only peer supports
What comes to my mind is UA sometimes has preference in conveying DTMF
in signaling path (INFO, NOTIFY) or telephone-event in media path.
So suppose A and B is in talk,
If A does not prefer convey DTMF in telephone-event, it send offer as
follows,
m=audio 49170 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
B gets this offer, it prefer to receive DTMF as telephone-event, so
advertises it in answer.
m=audio 6678 RTP/AVP 0 4 101
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:110 telephone-events/8000
So A knows and rfc3264 allows, dtmf can be sent to as telephone-event to
B.
However, if the dtmf preference reverses, the issues arises.
If A does prefer receive DTMF in telephone-event, it send offer as
follows,
m=audio 49170 RTP/AVP 0 4 101
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:110 telephone-events/8000
B gets this offer, it does NOT prefer to receive DTMF as
telephone-event, it answers as
m=audio 6678 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
However, it cannot send dtmf as telephone-event to A.
Even worse if A does not indicate DTMF support in signaling, A cannot
get any DTMF signal, which is a big service impact in real world.
Thanks
Regards,
-Rockson
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of T
Satyanarayana-A12694
Sent: Wednesday, August 19, 2009 1:50 AM
To: Paul Kyzivat (pkyzivat)
Cc: [email protected]
Subject: Re: [Sip-implementors] Can EP send media only peer supports
Sorry, I meant "Even if the answerer is prepared to receive"..
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of T
Satyanarayana-A12694
Sent: Tuesday, August 18, 2009 11:07 PM
To: Paul Kyzivat
Cc: [email protected]
Subject: Re: [Sip-implementors] Can EP send media only peer supports
Yes, I do agree that implementations have done a good job of working
with this ambiguity so far. And, it is not as much an issue.
However, I am having a difficulty to visualize a use case where the
offerer may use this "addl codec" to send media. Even if the offerer is
prepared to receive, the offerer would probably never use it (if he
could, he would have declared it in offer anyway).
So, wouldn't it help if we can add a qualifying statement to the spec:
"The answerer may add additional codecs in the answer. However, at the
time of writing this spec, there are no known use cases warranting this
condition."
Regards
Satya T
-----Original Message-----
From: Paul Kyzivat [mailto:[email protected]]
Sent: Tuesday, August 18, 2009 7:53 PM
To: T Satyanarayana-A12694
Cc: Dale Worley; [email protected]
Subject: Re: [Sip-implementors] Can EP send media only peer supports
The more I think about this "issue" the less I understand why it should
be an issue.
The answerer is under no obligation to include codecs that were not
present in the offer. And if it does so, there is no guarantee of
circumstances under which they might be used. And the offerer is
certainly free to ignore them.
So the only question is:
*If* the answer includes codecs that were not included in the offer, may
the offerer use them to encode media? And that is only an issue if the
answerer is *not* expecting them to be used.
So, if you are constructing an answer, don't include any codecs that you
aren't prepared to receive now. (If it hurts, don't do it.)
All we could possibly do by tightening up the wording is ensure that
even if mentioned, such codecs would not be used. What purpose would
that serve? And such restriction would only apply if both parties adhere
to it.
Thanks,
Paul
T Satyanarayana-A12694 wrote:
>
>
> -----Original Message-----
> From: Dale Worley [mailto:[email protected]]
> Sent: Tuesday, August 18, 2009 1:37 AM
> To: T Satyanarayana-A12694
> Cc: Paul Kyzivat; [email protected]
> Subject: RE: [Sip-implementors] Can EP send media only peer supports
>
> On Sat, 2009-08-15 at 23:35 +0800, T Satyanarayana-A12694 wrote:
>> Additional round trips should be made optional (only for
>> implementations having concurrent codecs limitation).
>>
>> Additionally, why can't the spec be modified (or place in a BCP):
>> 1. to allow only a sub-set (of what is present in the offer) in the
>> answer (or even just one codec)
>
>>> If you mean, "Is it allowed to put in the answer only a subset of
>>> the
> codecs that are in the offer", that is allowed now.
>
> No, I mean "Answerer must include only a sub-set of codecs present in
> the offer". Or "Answerer must not include any codec not present in the
> offer".
>
>> 2. to place a restrion on the offerer to only use one of the codecs
>> listed in the intersection of answer & offer.
>
> Some implementations use more than one codec, so that would have to be
> considered a BCP.
>
> Dale
>
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
