search for: rfc3264

Hi all! I updated my snom200 to 2.02t and now MOH from * don?t works anymore... only the MOH from snom server and if i clear the MOH server field in the phone i have no MOH at all..( with the transfer button, moh plays using a extension). Someone with that problem? I downgrade to 2.01s but nothing changes. Miklos -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi folks, in order to establish backward compatibility we made an image that automatically detects if the other side does not support RFC3264. Please try it out, we would be very interested if this image is a progress! http://snom.com/download/share/snom200-2.03b-SIP.bin Thanks, CS

Hi All, I have a problem with asterisk and call hold. In the re-invite package when I take the call to the hold, the SDP value "a=sendrecv" is present, according to the rfc3264 the sdp value a must be mark with "sendonly". I've already tried with Asterisk 1.8 and Asterisk 11, but there is the same problem. I've already read all the information about canreinvite and directmedia Can anybody help me? Thanks a lot Marco -------------- next part -----------...

I have an Asterisk 11.5 system, using SIP Realtime and operating as a ITSP. One of my customer's endpoints is a NetVanta 7100 PBX system that has a SIP trunk connection to my Asterisk box. The NV 7100 has a public IP on it that doesn't have any NAT between it and my Asterisk system. When the customer transfers a call from one handset to a voicemail box, the NV 7100 sends a RE-INVITE to

Running build 1.8.5.0 (compiled from source) I seem to be having an issue with codec negotiation. I have a Grandstream HT503 FXO port connected to a pstn line, a Polycom SP501, and a SIP trunk with callwithus. What I'm essentially looking to accomplish is for ulaw or g729 (preferably ulaw) to be used to the Grandstream FXO or any other internal endpoint, and for g729 only to be used outbound

...er. Similarly, under what conditions would we send a format to Bob that *was* in his endpoint allow= parameter but *wasn't* in the reconciled list we got from Alice via the core? Same possible options and questions as above. 3. OK now whatever we've decided to send to Bob, according to RFC3264 para 6.1, Bob MUST send back an answer that contains a common format OR reject the stream if there are no formats in common. It doesn't say whether it's valid for Bob to send back formats we didn't request *in addition *to ones we did request. It wouldn't make sense for him to do...

...ide band operation. ptime: duration of each packet in milliseconds. http://www.ietf.org/rfc/rfc4566.txt specify that in the ptime definition: "it is intended as a recommendation for the encoding/packetisation of audio". Thus, I would recommend to specify the same text as in rfc3264 for sdp offer/answer model: "If the ptime attribute is present for a stream, it indicates the desired packetization interval that the offerer would like to receive. The ptime attribute MUST be greater than zero." It might also be a good idea to say that even if an offerer w...

...; > ptime: duration of each packet in milliseconds. > > http://www.ietf.org/rfc/rfc4566.txt specify that in the ptime definition: > "it is intended as a recommendation for the encoding/packetisation of > audio". Thus, I would recommend to specify the same text as in rfc3264 > for sdp offer/answer model: > > "If the ptime attribute is present for a stream, it indicates the > desired packetization interval that the offerer would like to > receive. The ptime attribute MUST be greater than zero." > > It might also be a good idea...

...time: duration of each packet in milliseconds. >> >> http://www.ietf.org/rfc/rfc4566.txt specify that in the ptime definition: >> "it is intended as a recommendation for the encoding/packetisation of >> audio". Thus, I would recommend to specify the same text as in rfc3264 >> for sdp offer/answer model: >> >> "If the ptime attribute is present for a stream, it indicates the >> desired packetization interval that the offerer would like to >> receive. The ptime attribute MUST be greater than zero." >> >> It...

Hi all We are about to send an updated version of the internet draft "RTP Payload Format for the Speex Codec" to the IETF AVT working group. Before submitting we would like your input, if you have any comments or input please send them to the mailing list. If we don't get any comments in 1 week (by 22. May 2007) we will go ahead and submit it to the IETF. Of course you can comment