top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Origin State AVP in Diameter Protocol

+3 votes

I have a query regarding usage of Origin-State-Id AVP in Diameter. The Diameter Base Protocol RFC 3588 says that Origin-State-Id AVP MAY be included in any diameter message.

Now, some diameter based application (like a 3GPP defined application) defines new commands and in those commands’ ABNF Origin-State-Id AVP is not present.

Then does this imply that Origin-State-Id AVP MUST not be sent in these commands or it can be sent because RFC 3588 says it can be sent in any diameter message?

posted Aug 19, 2013 by Luv Kumar

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+3 votes

There are two aspects here.
1. As long as the command is extensible (i.e, has *[AVP] in its definition), Origin_State_Id can be added to the request/response.
2. Generally Diameter application specs address this issue, and decide to include/exclude Origin_State_Id. For example, Gx and Ro specs include it because as session oriented protocols, they recommend the usage of Origin-State-Id to detect peer restart. Sh, Cx etc don't include it because they don't use multi-transaction sessions.

So yes, it can be added . But from interoperability perspective, you may have to make sure that the remote end would use it they way you expect.


answer Aug 20, 2013 by anonymous
Similar Questions
+2 votes

Can someone please explain, what is the significance of "0" and non"0" value of Origin-State-Id AVP in a diameter message ?

+5 votes

What is the actual Cause of Election state In DIAMETER protocol and what would be the Diameter Behavior after that ?

+1 vote

From the RFC 6733, it is clear that diameter session is identified bases on session-id, which has to be globally unique. Also in section 2.5 (Connections vs Sessions), its clearly mentioned that one connection can be used to multiplex multiple diameter sessions.

I have following questions related to diameter session -
Is there any implicit correlation between diameter session and origin-host? Does diameter standard allow different requests for the same session to have different origin-host value? Is there any possible problem if the value of Diameter Identity (part of recommended format for session-id) is different from those present in the request (like origin-host/origin-realm)?

+2 votes

Based on the 3GPP 29.272, the IDR (Insert-Subscriber-data Request message) is generated by the HSS to the MME to update the subscriber profile in the MME and/or requesting subscriber info such as location-information, subscriber state...
However the SUBSCRIPTION-DATA AVP containing the of profile to be added or updated is defined as Mandatory.
What should contain this AVP if the IDR is sent only for requesting subscriber-info without updating the subscriber profile.
Should ot be present without any nested AVP under it?