Subject: Another question and a proposal

From: "Dan Firac" <[email-masked]>
Date: Sun, 2 Sep 2001 17:30:36 +0300

Hello,

1)The SIP rfc shows in the B.5 example a SDP message announcing two channels,
one for audio and one for telephone-events. The DTMF channel is announced without the redundancy mechanism.
I will try to compose an SDP message for the same case but with the redundancy mechanism, and I want you to tell me if it is correct?:

m=audio 6000 RTP/AVP 0                             ;audio channel
m=audio 6002 RTP/AVP 97 96                       ;digit channel
a=rtpmap:97 telephone-events                        ;dynamic pt for digits
a=fmtp:97 0-15                                              ;supported events
a=rtpmap:96 red                                            ;dynamic pt for redundancy mechanism
a=fmtp:96 97                                                 ;redundancy of the 97 codec ???

2)Proposal:
The RFC2833 says that the redundancy mechanism (RFC2198) is optional.
So, if a SIP device supports both RFC2833 and RFC2198 than it SHOULD insert both dynamic payload types
for the telephone-events and for redundancy mechanism in the format list for the digit channel (as above), not just
the redundancy mechanism. There are many devices implementing the telephone-events without the redundancy mechanism so the announcement of redundancy mechanism SHOULD be done together with the announcement of telephone-events for motives of compatibility.
Anyway, I can't see how one can announce in the format list ONLY the redundacy mechanism dynamic payload type, because it must define also the dynamic payload type for the telephone-events.

I think my proposal brings some clarifications (especially for the beginners) because I didn't find any complete example of 
the RFC2833 and RC2198 used together!!!!!

3)I also think that the RFC2833 should contain more examples of carrying digits through the redundancy mechanism;
or, at least, more detailed explanations about that '911' example.

4) One final question for the sustainors of the RFC2833 and redundancy mechanism. 
It is obvoius that in order to beneficate of the redundancy mechanism the user must type the digits very fast, so that the application catch many digits in a 2.048 sec interval. If the user types the digits with a time distance between them greater than 2.048 sec, the redundancy mechanism is USELESS, or am I wrong? 
The last situation is very real: e.g. when I want to 'talk'  to my home robot to see if there are new messages for me.
A  rapid solution would be the retransmission of the redundant messages, but you have to admit that it is UGLY.

Finaly, I must salute the ones who have chosen the '911' example in RFC2833 for their obiectivity. Of course, the user is calling '911', he is in a great hurry, so he will type very fast the number and he will be under the bound of 2.048 seconds and so the redundancy mechanism will work at his maximum parameters, isn't it?.  :-))))))))))))))

So, '911' is the optimal combination. What would we do with the others?
If there were 7 or more bits for the timestamp of the redundant events, I wouldn't be so sarcastic.

You, SDP wizards, should find an optimal solution for carrying ALL the numbers, otherwise the users will receive along with the SIP product a little warnning : "Dial fast! or else....".

Best regards,
Dan Firac
Software Engineer,
Redline Communications.