Can anyone tell me if there is an accepted standard for the following call scenarios. I have seen three different implementation across three different vendors and I have not been able to find anything specific in the RFC's.
Scenario 1: Modem/Fax call across G.729 When an end point detects the tones and decidecs to drop back, upspeed, or whatever term you want to use, should it send some kind of message or just start sending G.711 RTP? Scenario 2: DTMF Relay and Silence Suppression negotiation Using G.711, if the Invite requests DTMF Relay (RFC 2833) or Silence Suppression what would you expect the other end to do if it was set to not use them? Also, would you expect any difference in behavior for the reverse of this situation where the Invite does not have relay or suppression and the other end is set to use them? Would you expect it to reply in the 200 OK with whatever it was set to use or should it override its setting with what was in the Invite? This is assuming that the device only has two settings (yes or no). Also, if it replied back without relay or suppression, would you expect it to accept it from the far end and just not send it out? Or another possibility would be to not expect it from the far end but send it out itself (assuming that since the far end requested it, it would accept it)? Some of the differences in implementation I have seen boil down to expectations. If an end point requests relay or suppression does that mean it wants to send it, receive it, or both? Some assume that if it is in the Invite that the user is going to send it and others that it wants to receive it. As an example the Invite requested relay (i.e. 101) and the 200OK did not have it included as an option. However the requesting end still sent the 101 packet types and the far end decodec them. However the far end sent its tones back to the originator inband. This is creating some very difficult interoperability situations so I wanted to see if there was a consensus as to how it SHOULD behave. Thanks in advance Michael Davidson _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
