Hello,
As per RFC 4566 for RTP based applications, AS gives the RTP "session
bandwidth" as defined in RFC 3550 section 6.2.
"session bandwidth" as per RFC 3550: for each session, it is assumed that the
data traffic is subject to an aggregate limit called the "session
bandwidth" to be divided amon
Yes
On 19 Sep 2014, at 16:20, Dale R. Worley wrote:
>> From: Adrian Georgescu
>>
>> Blink uses this for Screen sharing using VNC protocol:
>>
>> m=application 2855 TCP/TLS/MSRP *
>> a=path:msrps://192.168.8.3:2855/52e5cab14755380a6d14;tcp
>> a=accept-types:application/x-rfb
>> a=setup:active
BFCP examples are:
m=application 5 TCP/TLS/BFCP *
a=setup:passive
a=connection:new
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=floorctrl:s-only
a=confid:4321
a=userid:1234
a=floorid:1 mstrm:10
a=floorid:2 mstrm:11
a=bfc
> From: Adrian Georgescu
>
> Blink uses this for Screen sharing using VNC protocol:
>
> m=application 2855 TCP/TLS/MSRP *
> a=path:msrps://192.168.8.3:2855/52e5cab14755380a6d14;tcp
> a=accept-types:application/x-rfb
> a=setup:active
> a=rfbsetup:active
My knowledge of MSRP is weak... Does this
On 9/19/14 1:20 PM, Kchitiz Saxena wrote:
Hi Brett
There is no received parameter in the request. Below is the Via header I
can see in the pcap taken at UAS -
Note that the message, as received by the UAS, won't contain a
"received" parameter. The UAS itself adds this parameter, and then
cons
Hi Kchitiz,
The point over here is that the layer 3 IP does not matched with
resolved IP address which is similar to the case of NAT. This way this case
can be handled as NAT scenario even though its not NAT case.
Rest it will depend on how you want to implement this scenario. You can
eith
Hi
I want to use early dialog REFER for implementing SRVCC functionality in IMS.
Can anyone tell me the significance of REFER in early dialog also how a UAS
will behave on receiving early dialog REFER.
Thanks
Anurag Khare
"DISCLAIMER: This message is proprietary to Aricent and is intended solel
Hi Kchitiz,
As per my understanding this will be implementation dependent there is no
specific standards, if client fqdn is resolving in two ip then it must be
trying to load balance. In A query response both Ip should have been received
therefore both of them should be compared with layer 3 ip
Hi Brett
There is no received parameter in the request. Below is the Via header I
can see in the pcap taken at UAS -
Via:SIP/2.0/UDP XX.YYY..net
;branch=z9hG4bKBW.-tsom1l-91.230.17.136V5060-0-107949759-1337557677-142656253-
When UAS resolves XX.YYY., it receives IP address B at top, t
No Vivek, its definitely not NAT. It is 2 IP addresses in DNS server for a
hostname.
On Fri, Sep 19, 2014 at 7:50 PM, Vivek Talwar
wrote:
> Hi,
>
> I think since address B is different from address A, client should
> treat this as some NAT is in place should send responses back to address A
Hi sip-implementors,
Below is an SDP example in RFC 3556:
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
m=audio 49170 RTP/AVP 0
Hi,
I think since address B is different from address A, client should
treat this as some NAT is in place should send responses back to address A
which is actual source IP received in Packet. Here, client can also treat
that Layer 3 ip and layer 2 ip are different and thus same logic of NAT
sh
Hi Kchitiz,
Concerning your question, you skipped the first part of section 18.2.2
bullet 3 (assuming UDP). If first part of bullet 3 is successful, the UAS
does not need to resolve the sent-by FQDN.
o Otherwise (for unreliable unicast transports), if the top Via
has a "received" par
Hi Brett
Thanks for the reply, can you please clarify it a bit more.
Yes, there is no maddr in Via header received. When UAS resolves FQDN
mentioned in Via header, it receives the "other"(Looks like UAC has 2
entries in DNS server for this hostname) IP address at top. Hence it sends
responses back
> My problem is following-
> Application receives an INVITE message from source IP address A with
FQDN
> in Via header. FQDN is resolved through DNS A query and receives DNS
reply
> where IP address B is mentioned at top and IP address A is mentioned
after
> that. So, all the responses are sent to
Hi
This is related to UAS behaviour to know "Where to send response for the
received request". Following two statement looks a bit contradicting to me -
1. RFC 3261, Section 18.2.2 - The server transport uses the value of the
top Via header field in
order to determine where to send a response.
Sam
16 matches
Mail list logo
