RE: : RE: AAA Transport Profile and Application Failure
Rakesh Mehta <[email protected]>
| Newsgroups | gmane.ietf.aaa |
|---|---|
| Message-ID | <[email protected]> |
Hi Marco,
Thank for your answer. Just for your clarification.
I am trying to write sh interface application (3GPP TS29.329) on top of diameter stack for 3GPP network. Here we have one request(PNR) message that server can send to client and client will send answer msg (PNA).
To receive this msg(PNR) , client must be subscribed with server through SNR msg.
client app -------> conn mgmt -------------->SNR------------>cm-------------->Server app(stateless)
client app <------- conn mgmt <--------------SNA <-----------cm<--------------Server app(stateless)
Now client application die.
client app ----X--- conn mgmt <--------------PNR <------------cm<--------------Server app(stateless)
client app ----X--- conn mgmt -------------->DUTDE--------->cm Server app(stateless)
cm --- connection mgmt;
DUTD ----DIAMETER_UNABLE_TO_DELIVER with e bit set.
Thanks,
Rakesh
STURA Marco Consultant <[email protected]> wrote:
Rakesh Mehta wrote
>As per section 6.1 of RFC 3588(as mentioned in this mail), even diameter stack is working in server mode; it can create DIAMETER_UNABLE_TO_DELIVER >message with E bit set and send to proxy if local application is not available to process the message.
>I believe this should be true for client side also, because the same scenario can occur for client side. can any person verify for me please???
I dont think this is the case. A Diameter client is not generating responses for requests it generated, clients just wait for answers. However, your case should be true for server initiated requests (e.g. RAR).
Regards
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com