Hi
proxy need not have a media function since media does not go through proxy.
But since proxy is aware of network configuration, media can be routed through
media server or gateway.
So for this to happen, there should be some signalling mechanism between media
gateway (server) and proxy.
So whenever there is a difference in network configuration, proxy should route the
media data through media server.
For this proxy needs to inform User Agents to send their media data to media
server instead of directly sending to other user.
I am not aware of any standard or spec that says about proxy server getting
network info.
Regards
Ranjit
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 03, 2004 5:28 PM
To: Avasarala Ranjit-A20990; 'sunil vatnal'; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [Sip-implementors] Codec negotiation
Ranjit,
The media part is transcoded only if the proxy server has media function embedded.
Let's assume that the proxy server doen not have media function and it's aware of some
of network configuration. Two questions here; 1. Is it really O.K that the proxy
server would change some information in SDP body of SIP INVITE message ?
- Back to the A and C case
1) A sends INVITE + SDP to the proxy server.
(SDP -> m: audio 3000 RTP/AVP 0 4 18, --> 0:g.711, 4:g.723,
18:g.729)
2) The proxy server forwards the INVITE + "modified" SDP
(SDP -> m: audio 3000 RTP/AVP 4 18, --> now g.711 has been
removed since the "C" is out of the local network)
==> Is it really possible ? As far as I know, the proxy server is not aware of
"SDP" unless it's working as an B2BUA...
3) B responses with 200 OK
2. Actually, no one can understand the network configuration except the "Router". The
real WAN interfaces are managed by the router of each network and neither the proxy
server or IP phone knows that specific information of the WAN interfaces.
- Is there any kind of standard specifications (or implementation
guidelines) that a proxy server could get network interface information such as trunk
type and bandwidth from the network ?
Regards,
Jun
-----Original Message-----
From: Avasarala Ranjit-A20990 [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 03, 2004 6:01 PM
To: sunil vatnal; [EMAIL PROTECTED]; [EMAIL PROTECTED]; sip- [EMAIL PROTECTED]
Subject: RE: [Sip-implementors] Codec negotiation
Hi Sunil
here since proxy is aware that user C is in a different network, it should
communicate with user C using G.729. so the media part is /transcoded/ before it goes
to user C.
So the media server, transcodes from G.711 to G.729 for C and vice versa for A.
Regards
Ranjit
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:sip-implementors- [EMAIL PROTECTED] On Behalf Of sunil
vatnal
Sent: Wednesday, November 03, 2004 2:04 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; sip- [EMAIL PROTECTED]
Subject: Re: [Sip-implementors] Codec negotiation
Guru,
The question is not only about the codec negotiation. It is mainly about the selection
of the codec for effective b/w utilization in this scenario.
All these IP phones A,B and C support G.711 and G.729. And when A is supporting G.711,
C also supports G.711 in this call. But, since C is in a different n/w with WAN
interface, G.711 would be expensive which consumes more b/w. So, G.729 is the right
codec here. Since, these endpoint terminals are not aware of the network
configurations, C does not have intelligence to do this.
What are the ways to select a proper codec here? Should the proxy server change the
codec when the message is being sent? If proxy is doing this job, how can it trace
what network interfaces the IP phones have?
I think I have made the question clear.
- sunil vatnal
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, November 03, 2004 4:48 PM
Subject: RE: [Sip-implementors] Codec negotiation
>
> Hi,
>
> With your Diagrammatic view, it is clear that proxy knows where user C
> is and when user A sends an invite; proxy intercepts and intern sends
> an invite to user C with user A media capabilities. If proxy does
> receive a 200 ok from user C it just forwards the message to user A.
> (User C is complaint with user A media capabilities). If this doesn't
> happen user C proposes its own media capabilities and codec
> negotiation can take place (Proxy may intercept with each or ip phones
> may have the intelligence to carry out msg transfers without proxy
> in-between.)
>
> Regards,
> Guru
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Wednesday, November 03, 2004 9:50 AM
> To: [EMAIL PROTECTED]
> Subject: [Sip-implementors] Codec negotiation
>
> Hi,
>
> When codec negotiation is taking place,
>
> - Since the endpoint terminals - usually IP phones - are not aware of
> the network configuration, How can the endpoint terminal (usually IP
> Phone) decide one of its codec capabilities ?
>
> For example, there're 3 users on the network.
> user A (IP phone, G.711, G.729 are possible, network 1.0.0.0)
> user B (IP phone, G.711, G.729 are possible, network 1.0.0.0)
> user C (IP phone, G.711, G.729 are possible, network 3.0.0.0)
> Proxy Server (network 1.0.0.0)
>
> A ----- B (same network, LAN)
> \
> P
> |
> |
> C (different network, WAN)
>
> In case when the call between A and C is taking place and when the
> bandwidth is concerned, How would they know that G.729 should be used
> instead of G.711 because they're not in the LAN environment ?
>
> Thanks
>
> /Jun
>
> _______________________________________________
> Sip-implementors mailing list [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
>
>
> Confidentiality Notice
>
> The information contained in this electronic message and any
> attachments
to this message are intended
> for the exclusive use of the addressee(s) and may contain confidential
> or
privileged information. If
> you are not the intended recipient, please notify the sender at Wipro
> or
[EMAIL PROTECTED] immediately
> and destroy all copies of this message and any attachments.
>
> _______________________________________________
> Sip-implementors mailing list [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
