Subject: [sipcore] Handling P-Early-Media authorization from UAC on PRACK and UPDATE request

From: Dinoop <[email-masked]>
Date: Thu, 9 Aug 2018 17:19:02 +0530

Hello,

RFC 5009 mainly talks about early media authorization  by UAS toward UAC
only. It is not clear how to handle the ealry media authorization request
coming from UAC. Currently we encountered an issue on our B2BUA
implementation.

As per the implementation requirement by the client, B2BUA has to repeat
the previous P-Early-Media value received from UAS towards UAC in all
supported messages (eg 18x, Update & PRACK ) messages. For an example if
UAS has sent P-Early-Media :senonly on 1st 18x, and if subsequent 18x from
UAS doesn't contain P-Early-Media header, then B2BUA has to remember the
P-Early-Media received on 18x and to provide it to UAC. This fine and works
well.

The issue started occurring network when B2BUA started sending
P-Early-Media in PRACk request towards UAS. For an example,

Exported from Notepad++
UAC B2BUA UAS | 1:INVITE(SDP) | | +----------------------->| | | 2:100[INV]
| | |<-----------------------+ | | | 3:INVITE(SDP) | |
+----------------------->| | | 4:100[INV] | | |<-----------------------+ |
| 5:180[INVITE](SDP) | | |<-----------------------+ | 6:180[INVITE](SDP)
|P-Early-Media=sendonly | |<-----------------------| |
|P-Early-Media=sendonly | | | | 7:183[INVITE] | |
|<-----------------------+ | 8:180[INVITE](SDP) | |
|<-----------------------| | | P-Early-Media=sendonly | | | | | | 9:PRACK |
| +----------------------->| 10:PRACK | | |----------------------->| | |
P-Early-Media=sendonly |

Here you can see the message 10 B2BUA repeated the P-Early-Media value of
that dialog towards UAS and caused issues at UAS.

The question is
1) How the P-Early-Media value sent by UAC is interpreted?
2) Can you please explain a P-Early-Media value of sendrecv, sendonly ,
recvonly & inactive by UAC has to be interpreted by UAS.
3) Can we treat P-Early-Media sent by UAS and UAC independently or is those
are relative?
4) If UAS sent P-Early-Media sendonly on 18x for enabling backward media
and if B2BUA has to include P-Early-Media (due to some business logic) in
PRACK request, what has to be the value (sendonly or recvonly)?. The value
must not affect backward media flow.

-- 
Thanks
Dinoop p

---

From: <[email-masked]>
Date: Thu, 9 Aug 2018 13:42:19 +0000

Hi,
Where do you have found this requirement in RFC5009 or is this your own requirement?
“As per the implementation requirement by the client, B2BUA has to repeat the previous P-Early-Media value received from UAS towards UAC in all supported messages (eg 18x, Update & PRACK ) messages.”

Here are some answers based on your assumption.

  1.  How the P-Early-Media value sent by UAC is interpreted?

Answer: Based on your use case, in a wrong way. Since early media is sent towards the UAC and not towards the UAS. So it is a wrong B2BUA implementation
PRACK is not sent towards the UAC. If you would like to sent such indication towards the UAS then it should change the direction and Question is why it sould be sent? Because the early media could be also invoked by the B2BUA.

2) Can you please explain a P-Early-Media value of sendrecv, sendonly , recvonly & inactive by UAC has to be interpreted by UAS.

Answer: This is written within RFC5009 as follows: The P-Early-Media header field includes one or more direction parameters where each has one of the values: "sendrecv", "sendonly", "recvonly", or "inactive", following the convention used for Session Description Protocol (SDP) [7<https://tools.ietf.org/html/rfc5009#ref-7>][8]

3) Can we treat P-Early-Media sent by UAS and UAC independently or is those are relative?

Answer: What do you understand relative. If you have an IVR then I assume it is relative. Announcement will be answered by an interaction of a user e.g. DTMF or verbal answer.

4) If UAS sent P-Early-Media sendonly on 18x for enabling backward media and if B2BUA has to include P-Early-Media (due to some business logic) in PRACK request, what has to be
the value (sendonly or recvonly)?. The value must not affect backward media flow.

Answer: See the interpretation of those values above.

Best Regards

Roland

Von: sipcore [mailto:[email-masked]] Im Auftrag von Dinoop
Gesendet: Donnerstag, 9. August 2018 13:49
An: SIPCORE <[email-masked]>
Betreff: [sipcore] Handling P-Early-Media authorization from UAC on PRACK and UPDATE request

Hello,

RFC 5009 mainly talks about early media authorization  by UAS toward UAC only. It is not clear how to handle the ealry media authorization request coming from UAC. Currently we encountered an issue on our B2BUA implementation.

As per the implementation requirement by the client, B2BUA has to repeat the previous P-Early-Media value received from UAS towards UAC in all supported messages (eg 18x, Update & PRACK ) messages. For an example if UAS has sent P-Early-Media :senonly on 1st 18x, and if subsequent 18x from UAS doesn't contain P-Early-Media header, then B2BUA has to remember the P-Early-Media received on 18x and to provide it to UAC. This fine and works well.

The issue started occurring network when B2BUA started sending P-Early-Media in PRACk request towards UAS. For an example,

Exported from Notepad++
   UAC                      B2BUA                    UAS
    |       1:INVITE(SDP)    |                        |
    +----------------------->|                        |
    |       2:100[INV]       |                        |
    |<-----------------------+                        |
    |                        |     3:INVITE(SDP)      |
    |                        +----------------------->|
    |                        |       4:100[INV]       |
    |                        |<-----------------------+
    |                        |   5:180[INVITE](SDP)   |
    |                        |<-----------------------+
    |    6:180[INVITE](SDP)  |P-Early-Media=sendonly  |
    |<-----------------------|                        |
    |P-Early-Media=sendonly  |                        |
    |                        |   7:183[INVITE]        |
    |                        |<-----------------------+
    |    8:180[INVITE](SDP)  |                        |
    |<-----------------------|                        |
    | P-Early-Media=sendonly |                        |
    |                        |                        |
    |   9:PRACK              |                        |
    +----------------------->|   10:PRACK             |
    |                        |----------------------->|
    |                        | P-Early-Media=sendonly |

    The question is
1) How the P-Early-Media value sent by UAC is interpreted?
2) Can you please explain a P-Early-Media value of sendrecv, sendonly , recvonly & inactive by UAC has to be interpreted by UAS.
3) Can we treat P-Early-Media sent by UAS and UAC independently or is those are relative?
4) If UAS sent P-Early-Media sendonly on 18x for enabling backward media and if B2BUA has to include P-Early-Media (due to some business logic) in PRACK request, what has to be the value (sendonly or recvonly)?. The value must not affect backward media flow.

Here you can see the message 10 B2BUA repeated the P-Early-Media value of that dialog towards UAS and caused issues at UAS.

The question is
1) How the P-Early-Media value sent by UAC is interpreted?
2) Can you please explain a P-Early-Media value of sendrecv, sendonly , recvonly & inactive by UAC has to be interpreted by UAS.
3) Can we treat P-Early-Media sent by UAS and UAC independently or is those are relative?
4) If UAS sent P-Early-Media sendonly on 18x for enabling backward media and if B2BUA has to include P-Early-Media (due to some business logic) in PRACK request, what has to be the value (sendonly or recvonly)?. The value must not affect backward media flow.

--
Thanks
Dinoop p

---

From: Ranjit Avasarala <[email-masked]>
Date: Thu, 9 Aug 2018 22:40:17 -0500

Hi Dinoop

The P-early-media header indicates to the receiving entity that media like
DTMF or pre-recorded announcements should be played.  Refer to RFC 5009 for
a detailed explanation of this header

On Thu, Aug 9, 2018 at 6:49 AM, Dinoop <[email-masked]> wrote:

> UAC B2BUA UAS | 1:INVITE(SDP) | | +----------------------->| | |
> 2:100[INV] | | |<-----------------------+ | | | 3:INVITE(SDP) | |
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>
>

---

From: Dinoop <[email-masked]>
Date: Fri, 10 Aug 2018 16:02:45 +0530

Including [email-masked]

---------- Forwarded message ---------
From: Dinoop <[email-masked]>
Date: Fri, 10 Aug 2018 at 15:57
Subject: Re: [sipcore] Handling P-Early-Media authorization from UAC on
PRACK and UPDATE request
To: <[email-masked]>

Hello Jesske,

Thanks for the explanation. The following points has to be clarified

As per RFC 5009 6.Overview of Operation
<https://tools.ietf.org/html/rfc5009#section-6>, it is stated that,
"

   The UAC and proxies in the network may also insert, delete, or modify
   the P-Early-Media header field in messages towards the UAS within the
   dialog according to local policy, but the interpretation of the
   header field when used in this way is a matter of local policy and
   not defined herein.  The use of direction parameter(s) in this header
   field could be used to inform the UAS of the final early media
   authorization status.

"
It is allowed to send the P-Early-Media by UAC/proxy towards UAS and is
interpreted based on the local policy. Having said that, there is no
standard defined to generalize the usage. An example given above is to
inform the UAS about the actual authorization which is applied.

For an example suppose the UAS requested early media authorization of *sendrecv
*in reliable 18x response and the proxy responsible for media authorization
for UAC modified it to *sendonly* and  sent towards UAC. It is because the
local policy allows only  backward media Now if the proxy wants to inform
the UAS about the actually applied media authorization it can insert a
P-Early-Media with value of* sendonly *in the PRACK request sent to UAS.

Is this correct.? I used the value sendonly in PRACK request according to
the following section 8.The P-Early-Media Header Field,
<https://tools.ietf.org/html/rfc5009#section-8>

"

   The parameter value "sendrecv" indicates a request for authorization
   of early media associated with the corresponding media line, both
   from the UAS towards the UAC and from the UAC towards the UAS (both
   backward and forward early media).  The value "sendonly" indicates a
   request for authorization of early media from the UAS towards the UAC
   (backward early media), and not in the other direction.  The value
   "recvonly" indicates a request for authorization of early media from
   the UAC towards the UAS (forward early media), and not in the other
   direction.  The value "inactive" indicates either a request that no
   early media associated with the corresponding media line be
   authorized, or a request for revocation of authorization of
   previously authorized early media.

"

It  states that the value of P-Early-Media has is absolute and the
value *sendonly
*always indicates backwards early media. ie. If UAC/Proxy includes
P-Early-Media:*sendonly *in PRACK request towards UAS informs UAS that only
backward media is authorized.
Can you confirm whether this is the correct understanding?
(I know in offer/answer model the direction attributes are relative and one
must sent SDP answer with a=recvonly/inactive for the offer received with
a=sendonly)

My reply for your questions are follows,

Answer: Based on your use case, in a wrong way. Since early media is sent
towards the UAC and not towards the UAS. So it is a wrong B2BUA
implementation

PRACK is not sent towards the UAC.

[Dinoop]: Sorry I made it confusing. I mean the PRACK request towards UAS
only.

If you would like to sent such indication towards the UAS then it should
change the direction

[Dinoop] But as per section 8.The P-Early-Media Header Field,
<https://tools.ietf.org/html/rfc5009#section-8>stated above the value is
absolute. Can you please check?

and Question is why it sould be sent? Because the early media could be also
invoked by the B2BUA.

[Dinoop] Our B2BUA implementation  do not insert P-Early-Media header
towards UAS. But it has to be ready to expect the header from UAC. Because
it is allowed as per RFC

Answer: What do you understand relative. If you have an IVR then I assume
it is relative. Announcement will be answered by an interaction of a user
e.g. DTMF or verbal answer.

[Dinoop] As explained above I meant the value of P-early media. As per the
example given above, If UAS requested *sendrecv *and the proxy allows on
backwards early media, the proxy can modify the header and sent *sendonly *to
UAC. Now when sending the PRACK request towards UAS proxy can indicate the
actual authorization applied. As per my understanding as like offer/answer
model it has to be *recvonly*. But considering section 8 of RFC 5009, it
must be *sendonly*.

Am I right?

On Thu, 9 Aug 2018 at 19:12, <[email-masked]> wrote:

> “As per the implementation requirement by the client, B2BUA has to repeat
> supported messages (eg 18x, Update & PRACK ) messages.”
>
>
>
> Answer: Based on your use case, in a wrong way. Since early media is sent
> towards the UAC and not towards the UAS. So it is a wrong B2BUA
> implementation
>
> PRACK is not sent towards the UAC. If you would like to sent such
> indication towards the UAS then it should change the direction and Question
> is why it sould be sent? Because the early media could be also invoked by
> the B2BUA.
>
>
> Answer: This is written within RFC5009 as follows: The P-Early-Media
> header field includes one or more direction parameters where each has one
> of the values: "sendrecv", "sendonly", "recvonly", or "inactive", following
> the convention used for Session Description Protocol (SDP) [7
> <https://tools.ietf.org/html/rfc5009#ref-7>][8]
>
>
> Answer: What do you understand relative. If you have an IVR then I assume
> it is relative. Announcement will be answered by an interaction of a user
> e.g. DTMF or verbal answer.
>
>
> PRACK request, what has to be
>
> *Von:* sipcore [mailto:[email-masked]] *Im Auftrag von *Dinoop
> *Gesendet:* Donnerstag, 9. August 2018 13:49
> *An:* SIPCORE <[email-masked]>
> *Betreff:* [sipcore] Handling P-Early-Media authorization from UAC on
> PRACK and UPDATE request
>
>
>
> Hello,
>
>
>
> PRACK request, what has to be the value (sendonly or recvonly)?. The
> value must not affect backward media flow.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

-- 
Thanks & Regards
Dinoop p

-- 
Thanks & Regards
Dinoop p

---

From: <[email-masked]>
Date: Fri, 10 Aug 2018 13:00:34 +0000

Hi,
Thank you for pointing to this section.
So seen on local policy you are right that including a PEM header into a Message towards the UAS will include the direction of em between UAS and UAC. i.e. no change of attribute.
I have compared it to our network implementation, but we do not actively implement this use case.
Seen from informative character it may be valuable. But practically I do see only minor use cases since I do not know how the preceding proxies have manipulated the PEM header.

So I hope we are now on  the same track.

PEM will be more interesting when considering multiples eraly media. Which of the authorized streams you would like to cut throught to the user.

Regards

Roland

Von: Dinoop [mailto:[email-masked]]
Gesendet: Freitag, 10. August 2018 12:33
An: SIPCORE <[email-masked]>; Jesske, Roland <[email-masked]>
Betreff: Fwd: [sipcore] Handling P-Early-Media authorization from UAC on PRACK and UPDATE request

Including [email-masked]<mailto:[email-masked]>

---------- Forwarded message ---------
From: Dinoop <[email-masked]<mailto:[email-masked]>>
Date: Fri, 10 Aug 2018 at 15:57
Subject: Re: [sipcore] Handling P-Early-Media authorization from UAC on PRACK and UPDATE request
To: <[email-masked]<mailto:[email-masked]>>

Hello Jesske,

As per RFC 5009 6.Overview of Operation <https://tools.ietf.org/html/rfc5009#section-6> , it is stated that,
"

   authorization status.
"
It is allowed to send the P-Early-Media by UAC/proxy towards UAS and is interpreted based on the local policy. Having said that, there is no standard defined to generalize the usage. An example given above is to inform the UAS about the actual authorization which is applied.

For an example suppose the UAS requested early media authorization of sendrecv in reliable 18x response and the proxy responsible for media authorization for UAC modified it to sendonly and  sent towards UAC. It is because the local policy allows only  backward media Now if the proxy wants to inform the UAS about the actually applied media authorization it can insert a P-Early-Media with value of sendonly in the PRACK request sent to UAS.

Is this correct.? I used the value sendonly in PRACK request according to the following section 8.The P-Early-Media Header Field,<https://tools.ietf.org/html/rfc5009#section-8>

"

It  states that the value of P-Early-Media has is absolute and the value sendonly always indicates backwards early media. ie. If UAC/Proxy includes P-Early-Media:sendonly in PRACK request towards UAS informs UAS that only backward media is authorized.
Can you confirm whether this is the correct understanding?
(I know in offer/answer model the direction attributes are relative and one must sent SDP answer with a=recvonly/inactive for the offer received with a=sendonly)

  1.  How the P-Early-Media value sent by UAC is interpreted?
Answer: Based on your use case, in a wrong way. Since early media is sent towards the UAC and not towards the UAS. So it is a wrong B2BUA implementation
PRACK is not sent towards the UAC.
[Dinoop]: Sorry I made it confusing. I mean the PRACK request towards UAS only.

If you would like to sent such indication towards the UAS then it should change the direction
[Dinoop] But as per section 8.The P-Early-Media Header Field,<https://tools.ietf.org/html/rfc5009#section-8>stated above the value is absolute. Can you please check?

and Question is why it sould be sent? Because the early media could be also invoked by the B2BUA.
[Dinoop] Our B2BUA implementation  do not insert P-Early-Media header towards UAS. But it has to be ready to expect the header from UAC. Because it is allowed as per RFC

Answer: What do you understand relative. If you have an IVR then I assume it is relative. Announcement will be answered by an interaction of a user e.g. DTMF or verbal answer.
[Dinoop] As explained above I meant the value of P-early media. As per the example given above, If UAS requested sendrecv and the proxy allows on backwards early media, the proxy can modify the header and sent sendonly to UAC. Now when sending the PRACK request towards UAS proxy can indicate the actual authorization applied. As per my understanding as like offer/answer model it has to be recvonly. But considering section 8 of RFC 5009, it must be sendonly.
Am I right?

On Thu, 9 Aug 2018 at 19:12, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
Where do you have found this requirement in RFC5009 or is this your own requirement?
“As per the implementation requirement by the client, B2BUA has to repeat the previous P-Early-Media value received from UAS towards UAC in all supported messages (eg 18x, Update & PRACK ) messages.”

Best Regards

Roland

Von: sipcore [mailto:[email-masked]<mailto:[email-masked]>] Im Auftrag von Dinoop
Gesendet: Donnerstag, 9. August 2018 13:49
An: SIPCORE <[email-masked]<mailto:[email-masked]>>
Betreff: [sipcore] Handling P-Early-Media authorization from UAC on PRACK and UPDATE request

Hello,

Exported from Notepad++
   UAC                      B2BUA                    UAS
    |       1:INVITE(SDP)    |                        |

    The question is

The question is

--
Thanks
Dinoop p

--
Thanks & Regards
Dinoop p

--
Thanks & Regards
Dinoop p