I am currently reading the newest CLOR 350-801 Cisco Press book. There is a section in the SIP-Protocols description which recaps how early offer and delayed offer works. Here is an excerpt from the book about early offer:
The OK message contains call connection status, acknowledgement that SDP information has been received, and the destination endpoints SDP information. Since the destination endpoint is now aware of the ports specified by the source endpoint for the media communication, these ports are opened, and the destination endpoint can now receive audio and video media over these UDP ports. Once the source endpoint receives the OK message from the destination endpoint, the UDP ports that are specified from that communication will be opened so that audio and video media can be received from the destination endpoint.
If I am not mistaken, the ports offered by the source in the SDP message are the ones it will listen on, and where the destination will send packets to, right? I think everything that’s marked in bold is incorrect.
The sentence should be: the destination endpoint can now send media to the ports specified by the source endpoint in the initial INVITE. Once the source endpoint receives the OK message from the destination endpoint, the UDP ports specified from that endpoint (destination) will be used to send media to.
Initial INVITE contains ports where media will be received on from the far end / Where source will listen on for incoming media.
200 OK from destination contains ports, where media will be sent to from the source and where the destination listens on for incoming media.
I hope my assumption is correct. Thank you for your feedback!
AFAIK know and can read from your excerpt it is correctly described in the book. The outtake from the book describe the function of the 200 OK message that the destination sends back to the original sender, where as your text describes the function of both the initial Invite and the answer in the 200 OK.
thank you for your reply. But lets just pick that part:
Since the destination endpoint is now aware of the ports specified by the source endpoint for the media communication, these ports are opened, and the destination endpoint can now receive audio and video media over these UDP ports.
The only message in a delayed offer which contains the SDP information at the receiving side is the ACK sent by the source.
The 200 OK from the destination towards the source also contains SDP information, of which some are related to ports.
But from my understanding each of these messages contain the port information, which will be opened locally and not as described at the far end:
Since the destination endpoint is now aware of the ports specified by the source endpoint for the media communication, these ports are opened...
This sentence implies that the far end opens the ports which it received from the ACK message from the source. And the source opens the ports which it received from the far end in the 200 OK.
The initial invite contains the SDP, so the receiver knows upfront what ports the sender will use and on what IP it can be reached. Further it contains a list of codecs it can support. Then the destination, aka the recipient of the initial invite, respond with a 200 OK, in which it will specify what port it would use, what IP it can be reached at and also what codec to use from the list of the once in the initial invite. Again this is what is said in the book IMHO.
I grant you that possibly the wording in the book is at point somewhat backwards/convoluted and this could be misleading if you don’t think of it from the perspective of whom in the dialogue is referenced in the text.
You want in some scenarios different URIs or call-IDs and different access code are used by guest and host participants to join a meeting, and different rights or privileges, for example add or remove participants, mute audio or video, or when there...
Opus is an adaptive codec that provides better audio call quality than G.711/G.729 voice codecs and in a low bandwidth environment. The codec has a very low algorithm delay and is it is highly scalable in terms of audio bandwidth, bitrate, and comple...
Background:When deploying a multisite with centralized call processing across multiple countries, the digit manipulation can be complex, in this scenario US Site as HQ, GE Site in Germany and AU Site in Australia use different dial plan.We need to unified...
Version 3.3 introduces the ability to schedule meetings and see upcoming meetings in web app. Web app users can schedule meetings, modify the scheduled meetings, and notify participants via email. Scheduler is a new component that enables scheduling meeti...
Translation Profile is used on Voice Gateway to perform Digit Manipulation on the Calling and Called Parties. The Translation Pattern is doing the same digit manipulation. The translation profile can be applied BEFORE the incoming dial peer is matched (if...