Does https://tools.ietf.org/html/rfc3264#section-8.3.1 describe this case, thus
it's ok?
23.06.2019, 22:22, "r...@yandex.ru" :
> Hi everyone
>
> Is it ok from SIP, SDP perspective changing "c", connection data in
> subsequent SIP/183 response.
>
> For example:
>
> INVITE --->
> <---
Hi everyone
Is it ok from SIP, SDP perspective changing "c", connection data in subsequent
SIP/183 response.
For example:
INVITE --->
<--- 183, c=IN IP4 1.1.1.1
<--- 183, c=IN IP4 2.2.2.2
___
Sip-implementors mailing list
Sip-i
only one media-line. It looks like
v=0
o=userX 199 2 IN IP4 10.62.130.136
s=-
c=IN IP4 10.62.130.136
t=0 0
m=image 50346 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:4000
a=T38FaxMaxDatagram:948
a=T38FaxUdpEC:t38UDPRedundancy
02.02.201
Hi everyone
Wondering if some of you have seen in the wild working sessions when originator
(fax machine as a rule) sends media=image (and other corresponding options) in
its initial INVITE and remote takes it without answering immediately SIP/501.
If I'm not mistaken this "image in initial" do
Shinji, thank you
I didn't get your first answer, now I do
24.01.2019, 04:43, "OKUMURA Shinji" :
> Hi,
>
> No B doesn't. B has not changed PAI of A. B has just indicated its own ID.
>
> Regards,
> Shinji
>
> On 2019/01/24 0:04, r...@yandex.ru wrote:
>> Thank you
>>
>> Does B violates some sta
Thank you
Does B violates some standard changing original PAI value?
21.01.2019, 11:09, "OKUMURA Shinji" :
> Hi,
>
> RFC3325/9.1
> Header field where proxy ACK BYE CAN INV OPT REG
> - - --- --- --- --- --- ---
> P-Asserted-Identity adr - o - o o -
>
> RFC
Hi everyone
Could some point to the doc or maybe clarify if B is correct in the following.
A sends INVITE to B. There is PAI header, lets say P-Asserted-Identity: "Alice"
B in reply (SIP/183 and SIP/200) sends for example P-Asserted-Identity: "Bob"
, that means PAI header completely differs f
